過去我們談了關於 Synchronous Feature (Realtime Feature) 和 Asynchronous Feature (Batch Feature) 的不一緻性，換句話說，也就是 Training Feature 和 Serving Feature 可能有著不同的計算邏輯，而這樣的誤差就會導致 Inference 本身多了一個不可控性，除了這點外在整個 Serving 過程中還有以下幾個問題

• Feature 缺乏一致性，如一開始提到的問題
• 由於 Feature Pipeline 在製作時綁定特定 Event 導致其他 Event Trigger 的 Model 無法重用, 跨模型共享
• Serving Feature Log 不具可回朔性，即使把 State 都存下來也無法重用
• Computation 和 Storage 難以分開
• Feature Value 缺乏版本控制

當然可以把所有 Event Log 都存下來，並重現發生過的 Event 來重新計算 PIpeline，但這樣計算速度很慢，所以這裡要提出一個 Feature Store 的 Solution 來解決以上的問題

什麼是 Feature Store？

Feature Store 是 Storage (滿常看到用 TiDB 實作)，用於存儲、查詢、和管理機器學習特徵，換句話來說 Feature Store 做了以下幾件事情

1. 把 Serving 和 Training 的資料來源統一放在一個 Storage
2. 固定時間 Snapshot 整個 Storage 來達到可重現性
3. 針對每個寫入的 Feature 增加額外的 Metadata 來做版本控制

透過以上的機制 Feature Store 可以做到幾點：

• 特徵重用和共享: 在傳統的機器學習工作流程中，特徵經常在不同的項目和團隊之間重複創建和計算。這不僅浪費了寶貴的計算資源，也增加了錯誤的風險。Feature Store 作為一個中央特徵倉庫，可以大大提高特徵的重用率。
• 特徵一致性: 確保用於訓練和服務（inference）的特徵一致是非常重要的。Feature Store 可以幫助實現這一點，因為它提供一個統一的平台來管理所有的特徵。
• 版本控制和追蹤: 與任何軟件項目一樣，特徵也需要進行版本控制。Feature Store 允許用戶跟踪特徵的更改和版本，這對於模型的可解釋性和可追溯性至關重要。
• 簡化工作流程: Feature Store 可以簡化特徵工程的工作流程，從而加速從數據預處理到模型訓練和部署的全過程。
• 集成與自動化: 在 MLOps 的框架下，Feature Store 可以輕易地與數據源、模型訓練平台、以及模型部署環境等集成，實現整個機器學習流程的自動化。

常見的 Feature Store Solution

• Feast: 開源，並且支援多種數據源以及存儲後端，並很好整合 Kubwflow 和 Airflow 等工具，然而學習曲線很高，很像 MLFlow
• AWS Feature Store: 需要整合 AWS 自家服務，並且有些 Timeout 設計需要自行實作
• Hopsworks Feature Store: 原生的 GDPR 支援，並且提供額外的資料分析工具，但缺點是比較複雜且架構設計上需要比較多計算資源

常見問題

然而我們可以看到上述的 Feature Store Solution 有幾個問題

1. 冷啟動時需要先有 pipline 才做特徵，或是要 backfilled 這些特徵
2. 有些特徵並不會隨時間改變，並不需要放到 Feature Store
3. 由於是固定時間間隔來做備份，在抓歷史資料難免還是有時間差

總結

重點不在於是不是要導入 Feature Store 到 MLOps 系統中，而是 Feature Store 為了解決的幾個問題是否帶給你們團隊困擾，當 Feature Store 的系統被建立且實作一段時間後，可以帶來的效益是提升模型上線速度 (因為特徵可重複使用)，並且更好的做後續的 Monitoring 機制

另外除了一開始提到的備份整個 Message Queue 來重現外，也很常見到使用 Spark RDD 特性來解決特徵醫治性的問題，總而言之，每個團隊會有最適合自己的方法，在 Serving 的部分我們就先停在這

補充 Inference Serving

Inference Serving 在 Structure Data 的 Binary Classification 中相對單純，不外乎是將模型包裝成一個 zip 並放到 Function as a service 的服務或是將 Model 包裝成一個 FastAPI endpoint 放到 Platform as a service 的服務中，或是透過 Kubernetes 來管理，由於這部分我認為這集比較多 DevOps 最佳實踐所以就不在這邊展開